home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / ietf / njm / njm-minutes-91mar.txt < prev    next >
Text File  |  1993-02-17  |  10KB  |  253 lines

  1.  
  2.  
  3. CURRENT_MEETING_REPORT_
  4.  
  5.  
  6.  
  7. Reported by Robert J. Reschly, Jr./BRL
  8.  
  9. NJM Minutes
  10.  
  11. Agenda
  12.  
  13. Old Business
  14.  
  15.  
  16.    o Unexpected routing.
  17.  
  18.       -  Reports
  19.       -  Operational Impact
  20.       -  Action
  21.           * Is there anything which should be done?
  22.           * Is there anything which can be done?
  23.  
  24.    o Other old issues - Communities?
  25.  
  26.  
  27. New business
  28.  
  29.    o Dale Johnson on trouble tickets.
  30.  
  31. Roundtable on current and expected issues
  32.  
  33.  
  34.    o Effects of development of Internet
  35.  
  36.  
  37.       -  Scaling
  38.       -  Speed
  39.       -  ``low budget'' connections, users?
  40.       -  International network coordination and mgt., etc.
  41.  
  42.  
  43. After a brief review of the function of the NJM, there was another call
  44. for ``unexpected routing'' anecdotes.  The University of Delaware to
  45. DuPont Delaware via Ithaca, NY and Reston, VA, and WestNET's 16 hops
  46. across town routes were cited as examples.  Also cited was the TWB
  47. routing problem due to that router being connected directly to the
  48. campus.
  49.  
  50.                                    1
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57. Others mentioned examples which were found to be a result of MILNET
  58. problems, and one situation involving Argonne.  All were understood and
  59. have been or are being corrected.
  60.  
  61. The subject of diagnosing routing problems came up.  Traceroute,
  62. especially third-party traceroute where available, still seems to be the
  63. most heavily used tool.
  64.  
  65. Tony Hain of ESNET informed those present of the community name for
  66. ESNET's routers.  This is strictly for use by other midlevel network
  67. operators in the performance of their tasks.  Others with a requirement
  68. to access these routers should contact Tony.  NSI is considering making
  69. it's community name available as well.
  70.  
  71. Dale Johnson briefly outlined this week's discussions concerning NOC
  72. trouble ticket systems.  He has a draft (draft-ietf-ucp-tt-00.txt),
  73. inspired by the UCP WG document (draft-ietf-ucp-connectivity-00.txt).
  74. He feels that their focus on accountability to end user problem reports
  75. and single NOC operations is not totally suitable for his purposes.
  76. Dale is more concerned with inter-NOC network oriented operations.
  77. Worth noting is that the TT discussions revealed a desire to make this
  78. more universally useful -- i.e., by central site staff as well as NOC
  79. staff.  Dale will be publishing an updated document in a few weeks.
  80. When questioned about whether any systems were going to be proposed, he
  81. responded affirmatively.  As a point of information, Gene Hastings
  82. stated he felt the real goal of the the UCP paper was the establishment
  83. of an inter-NOC transaction processing system for handling the passing
  84. of problem reports between NOCs.
  85.  
  86. MERIT currently runs an IBM mainframe product, but is moving towards a
  87. UNIX based TT system they may develop locally.  IBM Yorktown is working
  88. on xgmon; Tim Salo at MSC is funded to work on a UNIX implementation;
  89. and Sun Microsystems is working on one as well...  Word on developments
  90. will be sent to the Trouble Ticket Requirements mailing list
  91. <noc-tt-req@merit.edu> (-request for administrivia) as it becomes
  92. available.
  93.  
  94. There was quite a bit of talk about the pros and cons of basing a TT
  95. system on top of a DBMS. It is very easy to expend man-years of effort
  96. in the design and integration of a DB based system -- time many
  97. organizations simply do not have.  A suggestion that we encourage some
  98. company to produce and support a TT system was generally well received.
  99. It was also observed that in many cases, the integration of a TT system
  100. was going to involve some DB customization/interface work in any event.
  101.  
  102. A poll was taken about current TT operations.  10 sites have some sort
  103. of online TT system (4 were ASCII --['sensibly' printable]); 5 were
  104. paper systems; and three people reported having no formal TT system in
  105. use.  Someone noted there were two publicly available systems (are these
  106.  
  107.                                    2
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. in NOCTOOLS?).
  115.  
  116. Conversation then moved on to the desirabilty of having links to other
  117. portions of any existing DB -- examples involved things like
  118. specification of a router filling in configuration information, and
  119. mentioning a pair of routers completing link and telco contact
  120. information.  Again it was noted that this was a bigger win when the
  121. ``external'' components already existed.  It was observed that there
  122. must be products available which solve similar problems in areas like
  123. inventory control, but that they were not necessarily TT oriented.
  124. Unfortunately nobody could cite specific systems.
  125.  
  126. There was a call to formalize an operations track within the IETF.
  127. Having this track would reduce internal schedule conflicts, and should
  128. attempt to minimize conflicts with User Services as the two have
  129. significant overlap.
  130.  
  131. The group then dove into an extended discussion of the undesirability of
  132. referring all problems up towards MERIT. Members very much wanted the
  133. ability to contact relevant parties in other regionals directly, but
  134. expressed frustration at lack of contact information.  Many rely on one
  135. or more of the Internet Managers Phonebook, WHOIS, or stabs into the
  136. DNS, but these often are only approximate reflections of reality.  One
  137. proposal was the addition of text/hinfo records incorporating contact
  138. phone numbers.
  139.  
  140. Doug Gale  <dgale@nsf.gov>  is working on an NSF RFP for global user
  141. services..  [something about a help server at MERIT -- call
  142. (800)66-MERIT and ask about the help server].
  143.  
  144. There was a suggestion to add DNS records for networks as well as hosts
  145. (e.g., lookup on 128.63.0.0 -- forward and inverse), along with a
  146. warning that any records should match networks.txt.
  147.  
  148. Milo Medin had some comments concerning the new DDN NIC contract.  The
  149. new contract does not provide for network number assignment or DNS
  150. registration among other things.  [Later, Steve Wolff told us that DCA
  151. and NSF are working together to ensure the continuity of essential
  152. services.]  More information will be sent to the mailing list as it
  153. becomes available.
  154.  
  155. Kannan Varadhan then touched on his ongoing Telebit NetBlazer testing.
  156. He has developed a list of things he wants to discuss with Telebit, and
  157. solicits questions from others.  The NJM mailing list  <njm@merit.edu>
  158. (-request for administrivia) will host the dialog with Kannan as his
  159. testing continues (i.e., post your questions and answers to this list).
  160.  
  161.  
  162.  
  163.                                    3
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170. The basic NetBlazer is a 386 box running KA9Q, with 2 modem ports for a
  171. total cost of  ~$3,000.00.  Additional ports are added in 8 port
  172. increments.  It offers packet driven dialup, and three authentication
  173. methods:  username/password; callback; and, between boxes, a crypto
  174. handshake.  NetBlazer does not do TACACS.
  175.  
  176. The TACACS comment prompted a number of requests for some sort of
  177. authentication servers which may (at least optionally) be Internet-wide
  178. in scope.  Dale Johnson mentioned in passing that MERIT had just
  179. deployed one for MICHNET.
  180.  
  181. Milo then talked briefly about NSI's plan for having a single 800 number
  182. for his folks on travel.  When called, this number would route to a hunt
  183. group of lines local to that area.  He also mentioned that it was still
  184. possible to assign fixed IP addresses with this and still have routing
  185. work (under OSPF if it was a single area -- OSPF used best match.).
  186.  
  187. After the discussion was wrenched back to the agenda, it was asserted
  188. that overall European routing is a disaster, even if internal (i.e.,
  189. ESNET or NSI European routing appeared to be sensible).  Dave O'leary
  190. noted that in many cases routing was set based on technical
  191. considerations even when they conflicted with policy considerations.
  192. SURA continues to take heat on this issue.  It was felt that the
  193. FEPG/FRICC work would help.  The FEPG has developed guidelines which
  194. formalize connectivity in accordance with CCIRN recommendations.
  195.  
  196. At this point Milo insisted that NOCs contemplating international
  197. operation absolutely positively must have 24 x 7 NOC operations.
  198.  
  199. We were told that SPRINT and Cornell (the NSF International connection
  200. managers) want to schedule a global BGP, coordination and cutover
  201. meeting.  The current best guess has this meeting taking place at the
  202. July IETF in Atlanta.
  203.  
  204. Someone wondered if the decisions were unilateral or bilateral.  The
  205. IEPG is a technically oriented group doing sensible things, but it is
  206. not clear the IEPG is in a position to significantly affect the decision
  207. process.  Their next meeting is in Paris in early May.  It was also
  208. noted that many of the problems appeared to be intra-European.
  209.  
  210. We then moved on to a very brief consideration of what connecting hordes
  211. of high schools would entail.  A quick survey showed three regionals are
  212. planning to connect 10 or more high schools in the coming year, and in
  213. at least one case, these connections will connect whole districts.
  214.  
  215. The humor quotient chose that time to take a significant nosedive so we
  216. adjourned.
  217.  
  218.                                    4
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225. Attendees
  226.  
  227. Vikas Aggarwal           vikas@JVNC.net
  228. Jordan Becker            becker@nis.ans.net
  229. Tom Easterday            tom@cic.net
  230. Dale Finkelson           dmf@westie.unl.edu
  231. Vince Fuller             vaf@Standford.EDU
  232. Shari Galitzer           shari@gateway.mitre.org
  233. Joseph Golio             golio@cray.com
  234. Eugene Hastings          hastings@psc.edu
  235. Steven Hunter            hunter@es.net
  236. Dale Johnson             dsj@merit.edu
  237. Dan Jordt                danj@nwnet.net
  238. Daniel Long              long@nic.near.net
  239. Milo Medin               medin@nsipo.nasa.gov
  240. Bill Norton              wbn@merit.edu
  241. David O'Leary            oleary@sura.net
  242. Robert Reschly           reschly@brl.mil
  243. Ron Roberts              roberts@jessica.stanford.edu
  244. Roxanne Streeter         streeter@nsipo.nasa.gov
  245. Kannan Varadhan          kannan@oar.net
  246. Ross Veach               rrv@uiuc.edu
  247. Carol Ward               cward@spot.colorado.edu
  248. C. Philip Wood           cpw@lanl.gov
  249.  
  250.  
  251.  
  252.                                    5
  253.